Session Initiation Protocol (SIP) is the signaling protocol of choice for session initiation and termination in the Internet (See Rosenberg J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002). SIP supports voice, video, and multimedia sessions that are very sensitive to the Quality of Service (QoS) provided by the underlying network.
There have been a lot of efforts to provide QoS for SIP-based sessions. The proposed solutions fall into two classes: (1) QoS reservations are serviced by SIP user agents (See Marshall, B. (ed), Private Session Initiation Protocol (SIP) Extensions for Media Authorization, RFC3313, 2003, and Camarillo, G., Marshall, B., Rosenberg, J., Integration of Resource Management and Session Initiation Protocol (SIP), RFC3312, 2002); and (2) QoS reservations are serviced by SIP servers (See Salsano, S., Veltri, L., QoS Control by Means of COPS to Support SIP-Based Applications, IEEE Network, March/April 2002). Both classes of solutions require modifications to the currently deployed SIP infrastructure. For example in Marshall, the basic concept mandates SIP user agents to use Resource Reservation Protocol (RSVP) for bandwidth reservation during the SIP call setup. In this case, the caller or source sends a SIP message (i.e., Invite) specifying that a bandwidth reservation is needed (e.g., using a pre-condition field in the SIP Invite); upon receipt of the SIP message, the callee or destination starts resource reservation by sending a RSVP path message (the caller also starts the process of resource reservation in the case of a bidirectional call). If the reservation is successful, the normal SIP flow of messages continues (an OK message towards the caller followed by an ACK message towards the callee).
Thus, existing solutions for providing QoS for SIP sessions suffer from a number of limitations such as the requirement for modifications to the currently deployed SIP infrastructure including SIP user agents and servers, the lack of scalability since they require interactions with the underlying network for resource reservations for each SIP session, a serious impact on the SIP session setup response time since they require interactions with the resource reservation system during the session setup; and inflexibility since they cannot be parameterized or policy-driven. No scheme has yet been identified in the public literature that supports QoS provisioning and assurance for SIP sessions without requiring amendments/modifications to the SIP infrastructure. Existing schemes require either SIP agents/clients to make the necessary resource reservations using, for example, RSVP (see Media Authorization with RSVP in Marshall and Preconditions in Camarillo) or propose changes to the SIP server to handle QoS provisioning in Salsano. In addition to these drawbacks, they are also not scalable since they require resource reservations per SIP session; e.g., for each session, RSVP is used to establish reservations. Assuming arrival of thousands or hundreds of thousands of concurrent session setup requests, as will be the case in public networks, this may have a considerable impact on the performance of the system including the underlying network.